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(54) Abstract Title 

A debugger interface unit for identifying selected eKcefrtions 

(57) A debugger irrterface unit 150 includes an exception routine catch logic which receives a first signal 
when a processorrore lOOIssues an instruction fetch command for an exception routine, determines from the 
address issued wim the fetch command which exception routine Is being fetched, references a control register 
having a number^ settable fields, each corresponding to a particular exception routine to determine whether 
the debugger wisfies to identify an access to that exception routine and. if so. outputs a breakpoint signal to 
the processor «re. stopping processing and ellowing the current stste of the processor to be examined. The 
debugger mterfece unit may also include one or more hardware breakpoint units 200. 205 including registers 
Snfto "ttnbutes of instruction or data accesses which. If detected will also cause a breakpoint sIgnS to be 
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APPARATUS AND METHOD FOR IDENTIFYING EXCEPTION.^ 
WHEN DEBUGGING SOFTWARE 

Ffeid of the Invention 

The present invention relates to an apparatus and method for debugging 
software, and in particular to an apparatus and method that facilitates the 
identification of exceptions when debugging software for a data processing apparatus. 
Description of the Prior Art 

: .^-KkArJ^ data processing apparatus may have a processor core arranged to 
exjb^te a sequence of instructions that are applied to data values supplied to the 
processor core. Typically, a memory may be provided for storing the instructions 
acd data values required by the processor core. Further, it is often the case that one 
otmore caches are provided for stormg instructions and data values required by the 
processor core, so as to reduce the number of accesses required to the memory. 

When debugging the software to be executed by such a data processing 
affiarafiis, it is known to use a debugger application executing on a computer 
(collectively referred to hereafter as a "debugger") to monitor the activity of the data 
processing apparatus as it executes the software. 

The debugger can be arranged to interface with the data processing apparatus 
via an emtedded "In Circuit Emulator" (ICE) unit provided within the data processing 
ai^^ttis. Typically, such embedded ICE units will contain a few hardware 
b?^liPpint units, each hardware breakpoint unit having a number of brealqwmt 
registers for storing attributes of instruction or data accesses that the debugger is 
interested ;in identifying, and a breakpoint comparator for comparing the attributes in 
^the^breakpoint registers with information received from the data processing apparatus 
abput instruction or data accesses being initiated by the processor core. The 
bti^^binf will typically inchide data registers, address registers and control 

registers for storing attributes of data, addresses or control signals, respectively. 
Further, mask fields may be provided to enable "don't care" states to be set up, for 
example when certain bits of the address are not of interest. 

Each hardware breakpoint unit may be arranged to issue a brealq)oini signal 
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to the processor core if the breakpoint comparator matches the attributes of the 
breakpoint registers with corresponding attributes contained in the information about 
instruction or data accesses received from the data processing apparatus. 

The breakpoint signal issued by a hardware breakpoint unit will cause the 
5 processor core to stop processing instructions, thereby enabling the debugger to 
analyse the current state of the data processing apparatus. 

When debugging software executed by such a data processing apparatus, it is 
highly desirable to be able to trap whenever an exception occurs during the execution 
of the code. An example of such an exception might be a data abort, i.e. where a 
10 data memory access occurred to a non-existent memory location. In this case, the 
memory system would return an error, and the processor would branch to a special 
routine, known as an "exception routine" via an exception address known as a 
"vector" address, the exception routine being provided to handle the occurrence of 
a data abort. 

15 One known technique for identifying an access to such an exception routine 

is to include in the breakpoint registers of one of the hardware breakpoint units 
attributes identifying the first instruction of that exception routine. By this approach, 
when the processor core issues an instruction fetch request including the address of 
that instruction, then the breakpoint comparator in the hardware breakpoint unit will 

20 match the instruction fetch request with the attributes in the breakpoint registers, and 
will issue the breakpoint signal. 

However, there are two main disadvantages to the above approach. Firstly, 
in most microprocessors there are many different types of exceptions, and hence 
many different exception routines provided to handle those exceptions, each exception 

25 routine having different instruction addresses. Hence, there will typically be many 
different instruction addresses which would require breakpointing if the above 
approach were to effectively identify accesses to any of those exception routines. 
However, due to cost factors (eg silicon cost), an embedded ICE unit typically only 
contains a small number of hardware breakpoint units, and hence it is undesirable to 

30 restrict their use to identifying accesses to exception routines, this process often being 
termed in the art "Vector Trapping" or "Vector Catching". 
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As an example, the ARM microprocessor developed by Advanced RISC 
Machines Limited has eight types of exception, and hence eight exception routines, 
each with unique instruction addresses, but generally only has two haniware 
breakpoint units. The eight types of exception, along with their addresses, are 
indicated below: 
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ADDRESS 


EXCEPTION ROUTINE | 




Reset 1 




Undefmed Instruction 


0x00000008 


Software Interrupt 


OxOOOOOOOC 


Prefetch Abort 


0x00000010 


Data Abort 


0x00000014 


Reserved 


0x00000018 


Interrupt 


OxOOOOOOlC 


Fast Interrupt 



20 



25 



As will be noted from the table, certain bits of the address are the same for 
each exception routine. To enable all of these various types of exceptions to be 
identified by a single hardware breakpoint unit, "don't care" states typically have to 
be set up in, the breakpoint address registers to ensure that the hardware breakpoint 
unit will identify an access to any of the exception routines. However, using such 
"do^-^" :^tes may mean that the processor core is stopped more often than it 

An alternative approach is to employ a "software breakpoint" technique. 
When,using a software breakpoint technique, a fixed pattern of bits is placed within 
the breakpoint data registers of a hardware breakpoint unit, and the breakpoint 
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comparator will then always compare the information received about instruction 
accesses with that fixed pattern. Then, the first instruction of each exception routine 
is removed from memory and replaced with the fixed pattern of bits. By this 
approach, when the processor core issues an instruction fetch request to that address, 
5 the fixed pattern of bits will be retrieved, and the breakpoint comparator in the 
hardware breakpoint unit will then match that pattern of bits with the pattern of bits 
stored in the breakpoint registers, and hence issue the breakpoint signal to the 
processor core. This breakpoint signal will then cause the processor core to stop 
processing instructions, so that the debugger can then examine the state of the 

10 processor and/or memory. 

However, if the software breakpoint approach is adopted, then this means that 
it is impossible to debug ROM code, since the instructions in ROM cannot be 
overwritten by the fixed pattern of bits. Further, if the data processing apparatus 
employs a cache, and if the instruction to be overwritten by the fixed pattern of bits 
15 is in the cache, then it may not be possible to overwrite that instruction in the cache, 
and so that instruction must be flushed from the cache, since otherwise the instruction 
will be returned from the cache without any access to the memory taking place, and 
hence without the fixed pattern of bits being retrieved. This is particularly 
disadvantageous if the code is stored in a "locked-down" portion of the cache, a 
20 locked-down portion typically being used to store a number of instructions that are 
used regularly by the processor core, and/or routines which require deterministic 
behaviour (ie determinable execution time), and hence should not be overwritten by 
new insuiictions retrieved from memory. 

Another problem with the above identified techniques is that some 
25 microprocessors allow the location of the exception routines, or "vectors" as they are 
sometimes called, to be changed. For example, the MIPS architecmre allows the 
vectors to move position based on the state of the "Bootstrap Exception Vector" 
(BEV) bit. For more information on the MIPS architecture, the reader is referred to 
the publication "MIPS Rise Architecmre" by Gerry Kane, Prentice Hall ISBN 0-13- 
30 584293-X. The base of the vectors may be changed under software control without 
the debugger being aware of the change. This may mean that vector accesses are not 
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i »i}glU when iising the above described breakpoint techniq^ 
- T Given the above identified problems with the prior art approaches, it is an 
<*ject of the present invention to provide an improved technique for identifying 
excq}tions when debugging software. 
5 Summafv n f the Invention 

Viewed from a first aspect, the present invention provides a debugger interface 
unit for a data processing apparatus, comprising: a control register havmg a number 
of. .fields, -each field corresponding to a particular exception routine, and each field 
being settable to indicate that the debugger wishes to identify an access to the 
^® corresponding exception routine; an exception routine catch logic arranged to receive 
first signal when a processor core within the data processing apparatus issues an 
instruction fetch command for an exception routine, and to determine from an 
iitttniction address issued with the instruction fetch command which exception routine 
is being fetched; the catch logic further being arranged to reference the field of the 
15 control register corresponding to the determined exception routine to determine if that 
fi|gi^tebeen set, and if the field has been set, to output a breakpoint signal to the 
processor core. 

In accordance with the present invention, the debugger interface unit, or the 
r enibedded ICE unit as it was referred to earlier, is adapted to include additional 
20 elements for facilitating the identification of exceptions when debugging software. 
...^ These additional elements comprise exception routine catch logic that is arranged to 
signal when a processor core within the data processing appaiatus 
issues in instruction fetch command for an exception routine. Further, a number of 
fie^<^ ^re provided within a control register of the debugger interface unit, each field 
25 coiTCspondiiig to a particular exception routine, and each field being settable to 
indicate that the debugger wishes to identify an access to the corresponding exception 
routine. The exception routine catch logic uses the instruction address issued with 
the instruction fetch command and the information stored in the fields of the control 
register to-determine which exception routine is being fetched, and to output a 
30 brealq)pim.signal to the processor core if the corresponding field has been set. 

The^ provision of such an exception routine catch logic frees any general 
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hardware breakpoint units provided within the debugger interface unit for use for 
other purposes, since none of the hardware breakpoint units need to be reserved for 
identifying accesses to exception routines. Further, the identification of accesses to 
such exception routines is independent of the base address of the exception routines. 

5 In preferred embodiments, the first signal is a signal output by the processor 

core on a control bus to request an instruction fetch for an exception routine to be 
performed. Preferably, the first signal consists of a signal output by the processor 
core to indicate that an instruction fetch is required (hereafter referred to as an 
InMREQ signal) and a qualifying signal to indicate that the instruction fetch relates 

10 to an exception routine. Typical debugger interface units, such as an embedded ICE 
unit, are already arranged to receive the InMREQ signal, and hence the debugger 
interface unit only needs to be adapted to receive the qualifying signal. 

It will be appreciated by those skilled in the art that the size of the fields in 
the control register may be chosen at will, assuming sufficient space is available 

15 within the debugger interface unit. However, in preferred embodiments, each field 
contains a single bit to indicate whether the debugger wishes to identify an access to 
the corresponding exception routine. This provides the most efficient use of space 
in the control register. 

The catch logic may be arranged to examine the whole instruction address 

20 issued with the instruction fetch command in order to determine which exception 
routine the instruction fetch command relates to. However, in preferred 
embodiments, the catch logic is arranged to determine from predetermined bits of the 
instruction address issued with the instruction fetch command which exception routine 
the instruction request command relates to. In situations where only a predetermined 

25 subset of the bits of the instruction address are needed in order to determine which 
exception routine is being accessed, then the above approach is more efficient than 
examining the whole instruction address. 

In preferred embodiments, the debugger interface unit further comprises an 
input terminal for receiving information about instruction or data accesses being 

30 initiated by the processor core; one or more hardware breakpoint units, each 
breakpoint unit having a number of breakpoint registers for storing attributes of 
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instruction or data accesses that are to cause the breakpoint signal to be sent to the 
processor core, and a breakpoint comparator for comparing the attributes in the 
breakpoint registers with the infonnation received at the input terminal; each 
. breakpoint^unit being arranged to issue said breakpoint signal if the breakpoint 
5 comparator . matches the attributes in the breakpoint registers with corresponding 
attriljutes contained in the information received by the input ten^ 

Jnentioned earlier, such hardware breakpoint units can be used to cause 
' ^'Snals to be issued when predetermined events occur. In addition to 

storing specific attributes of addresses, instructions, data values, or signals output on 
10 control tes. the breakpoint registers may also store mask information, such that 
certain attributes can be masked out. in effect providing a "don't care" function. 
. ifcneei a data mask can be added to the breakpoint registers to indicate that the 
br«ikpoiM comparator should not be concerned with certain portions of the data 
values remmed, and instead, the breakpoint comparator will use other attributes for 
15 con^arison; such as the address of instructions or data valuer 
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As mentioned earlier, by using the catch logic to perform the identification of 
accesses to exception routines, any such hardware breakpoim units provided are free 
to be used for other purposes, and none of the hardware breakpoint units need to be 
20 resented for identifying exception routine accesses. 

In preferred embodiments, the input terminal is comiected to an address bus. 
a data bus. and a control bus for receiving the infonnation about instmction or dati 
accesses being initiated by the processor core. The attributes stored within the 
breal^t registers may relate to addresses, data (including instruction data), or 
2^ .. attributes for signals output on die control bus. and hence in preferred embodiments 
the-inpufe terminal needs to receive information from the address bus. die data bus. 
and the control bus in order for the hardware breakpoint units to have access to aU 
the nraessary information required. 

:p.B«in^prefeiTed embodiments, the debugger interface unit further comprises a 
logic gate for receiving the breakpoint signal issued by any of the breakpoint units or 
the catch logic, and for outpuning a single signal to the processor core. If the 
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breakpoint signal takes the form of a logic "1" value, then the logic gate is preferably 
an OR gate. 

Further, in preferred embodiments, the debugger interface unit further 
comprises an interface for receiving attributes from the debugger for storing in the 

5 breakpoint registers. This interface preferably takes the form of a serial interface 
such as an IEEE Standard 1149.1-1990 JTAG serial interface, whereby the debugger 
interface unit can scan in data to be added to the breakpoint registers. 

In preferred embodiments, the conttol register has a further field settable to 
indicate that a stepping process is to be employed, the debugger interface further 

10 comprising: a state machine arranged to receive a second signal when a processor 
core within the data processing apparatus requests an instruction fetch to take place, 
the state machine being arranged to keep a record of the number of instruction fetches 
requested by the processor core; the state machine further being arranged to reference 
the control register to determine whether the further field has been set, and, if the 

15 further field has been set. to output the breakpoint signal to the processor core once 
a predetermined number of instruction fetches have been requested by the processor 
core. 

In prior art debugger interface units, such a stepping process would typically 
be performed by using one of the hardware breakpoint units. However, the provision 

20 of the state machine as defined above frees up the hardware breakpoint units to be 
used for other purposes, since one of the hardware breakpoint units does not need to 
be reserved for performing the stepping process. 

Preferably, the predetermined number of instruction fetches is two, and the 
stepping process is a single stepping process. Typical debugger interface units, such 

25 as an embedded ICE unit, are sensitive to a signal indicating when an instruction 
fetch is taking place. Hence, the state machine merely needs to keep a record of 
those signals, and, in accordance with preferred embodiments, when the second of 
those signals is received, then the breakpoint signal is asserted. By this approach, the 
next instruction is executed, and the processor then enters the debug state before 

30 doing anything else. 

Preferably, the second signal is a signal output by the processor core on a 
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control bus to request an instruction fetch to be performed (hereafter referred to as 
an InMREQ signal). As mentioned earlier, typical debugger interface units, such as 
an embedded ICE unit, are already arranged to receive the InMREQ signal, and 
hence all that is required is for the state machine to keep a record of the number of 
InMREQ signals received. 

Viewed from a second the present invention provides a data processing 
apparatus, comprising: a processor core for executing instructions; and a debugger 
inte^ unit in accordance with the first aspect of the present invention. 

In..accordance with this second aspect of the present invention, the debugger 
int^ce unit and the processor core are combined in one circuit, which may be 
pcp<led,iiKlependently of any other elements such as memory or cache. 

: The data processing apparatus may also include a number of other features, 
such as a memory directly accessed by the processor core, or a memory used in 
conjunction with one or more caches. In accordance with the Von Nemnami 
architecture, a single cache may be provided for storing both instructions and data. 
However, in preferred embodiments, a Harvard architecture is employed, and the data 
procttsing^ apparams hence fiirther comprises: an instruction cache for storing 
instructions; :a data cache for storing data; an instruction address bus and an 
instmction data bus being arranged to connect the instruction cache with the processor 
corcv the instruction address bus enabling the processor core to output instruction 
addresses to the instruction cache, and the instruction data bus enabling the processor 
core to receive instructions corresponding to those instruction addresses; and a data 
address bus and a data data bus being arranged to comiect the data cache with the 
Pi£^sor core, the data address bus enabling the processor core to output data 
addresses to the data cache, and the data data bus enabling the processor core to 
reeeive^ta values corresponding to those data addresses, or to output data values to 
the data^^cache. 

Preferably, the input terminal of the debugger interface unit is comiected to 
the^i^dn address bus and the instruction data bus for enabling the one or more 
hardware breakpoint units to receive the necessary information about instruction 
accesses required by the breakpoint comparator. Further, the input terminal of the 
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debugger interface unit is connected to the data address bus and the data data bus for 
enabling the one or more hardware breakpoint units to receive the necessary 
information about data accesses required by the breakpoint comparator. 

Further, the input terminal can be connected to both an instruction control bus 
and a data control bus in order to receive the necessary information that may be 
required by the hardware breakpoint units concerning signals output on these control 
buses. 

Viewed from a third aspect, the present invention provides a method of 
operating a debugger interface unit for a data processing apparams to identify an 
access to an exception routine, comprising the steps of: (a) providing a number of 
fields within a control register, each field corresponding to a particular exception 
routine; (b) setting one of said fields to indicate that the debugger wishes to identify 
an access to the corresponding exception routine; (c) receiving a first signal when a 
processor core within the data processing apparatus issues an instruction fetch 
15 command for an exception routine; (d) determining from an instruction address issued 
with the instruction fetch command which exception routine is being fetched; and (e) 
if the field of the control register corresponding to the exception routine determined 
at said step (d) has been set, outputting a breakpoint signal to the processor core. 
Rriftf Description n f the Drawings 
20 The present invention will be described further, by way of example only, with 

reference to preferred embodiments thereof as illustrated in the accompanying 

drawings, in which: 

Figure 1 illustrates a data processing apparams in accordance with a first 
embodimem of the present invention, in which the data processing apparams has a 

25 Harvard architecture; 

Figure 2 illustrates a data processing apparams in accordance with a second 
embodimem of the present invention, in which the data processing apparams has a 
Von Neumann architecture; 

Figure 3 illustrates a data processing apparams in accordance with a third 
30 embodiment of the presem invention, in which the data processing apparams does not 
employ a cache, and instead the processor core is arranged to directly access 
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mraiory; 

Figure 4 illustrates the main elements of an embedded ICE unit in accordance 
with preferred embodiments of the present invention; 

: Figure 5 is a timing diagram illustrating the relationship between the various 
S signals relevant to the state machine of Figure 4; 

= - Figure 6 is a state diagram illustrating the relationship between the various 
states of the state machine illustrated in Figure 4; 

Figure 7 is a block diagram illustrating elements of the state machine 
illustrated in Figure 4; 
10 Figure 8 is a timing diagram illustrating the relationship between the various 

signals relevant to the vector catch logic illustrated in Figure 4; 

Figure 9 is a block diagram illustrating elements of the vector catch logic 
iUl^strated in Figure 4; and 

Figure 10 is a diagram illustrating the logic contained within the decode logic 
15 of-Figure 9. 

P^yirjpt^ffffi 9f a jPreferr^ Embodimept 
f?"rr ; Figure 1 illustrates a data processing apparatus in accordance with the first 
- embodiment of the present invention, in which the data processing apparatus employs 
a Harvard architecture having a separate instruction cache and a separate data cache. 
20 ^ As illustrated in Figure 1, the processor core 100 is connected to an 
instruction cache 110 via instmction bus lines, and to a data cache 120 via data bus 
liros. A single cache controller 130 is shown for controlling both the instruction 
cache 1 10 and the data cache 120. However, alternatively, separate cache controllers 
may be provided, one for the instruction cache 110 and one for the data cache 120. 
25 4 : When the processor core 110 requires an instruction, it places the memory 
address of that instruction on the instruction address bus 160, and also issues a 
processorv control signal on the instruction control bus 170. The processor control 
sij^ial includes information such as whether the address corresponds to a read or a 
wrife-request, the type of access (e.g. sequential), the size of the access (e.g. word. 
30 : ; byte), the operating mode of the processor (e.g. supervisor or user), etc. This 
procesror control signal is received by the cache controller 130, and prompts the 
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cache controller to determine whether the required instruction is stored within the 
instruction cache 110. 

In preferred embodiments, the processor control signal placed on the 
instruction address bus 160 when the processor core 100 requires an instruction to be 
5 retrieved is an Instruction Memory Request (InMREQ) signal, this signal informing 
the cache controller 130 that the instruction cache 1 10 should compare the address on 
the instruction address bus 160 with the addresses in the instruction cache 110 to 
determine whether the instruction corresponding to that address is stored within the 
cache. If so, the instruction is output from the instruction cache 110 on the 

10 instruction data bus 165, where it is then read by the processor core 100. If the 
instruction corresponding to the address is not within the cache 110, then the cache 
controller 130 causes the instruction to be retrieved from memory 140 via the external 
bus 220. The retrieved instruction is then stored in the cache 110 and returned to the 
processor core 100 over the instruction data bus 165. 

15 Similarly, addresses for data values may be output on the data address bus 

180, and a signal to indicate to the memory system that a data fetch is required 
(hereafter referred to as a Data Memory Request (DnMREQ) signal) is then output 
on the data control bus 190 to the cache controller 130. This will cause the data 
cache 120 to return the data value corresponding to that address on the data data bus 

20 185 if that data value is stored within the data cache, or otherwise the cache 
controller 130 will retrieve the data value from the memory 140, at which point the 
data value will be stored in the data cache 120 and returned to the processor core 100 
over the data data bus 185. Additionally, the processor core 100 can output data 
values to be stored in the data cache on the data data bus 185. 

25 In accordance with preferred embodiments of the present invention, the data 

processing apparatus is further provided with an embedded ICE unit 150, which is 
used as a debugger interface unit to an external debugger application executing on a 
computer such as a PC, this debugger application being referred to hereafter as a 
"debugger". In preferred embodiments, the embedded ICE unit 150 contains two 

30 hardware breakpoint units 200 and 205, each hardware breakpoint unit having a 
number of breakpoint registers for storing attributes of instruction or data accesses 
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that the debugger is interested in identifying, and a breakpoint comparator for 
comparing the attributes in the breakpoint registers with information received from 
the datrprocessing apparatus about instruction or data accesses being initiated by the 
processor core. This information from the data processing apparatus is provided over 
5 bus lines 160, 165, 170 and/or the various data bus lines 180, 

--1B5, 190. Each hardware breakpoint unit may be arranged to issue a brealqwint 
signal to the processor core if the breakpoint comparator matches die attributes of the 
breakpoint registers with corresponding attributes contained in the information about 
instruction or data accesses received from the data processing apparatus. 

0 To allow the debugger to update the breakpoint registers within the hardware 
breakpoint units 200 or 205. a serial interface such as a JTAG serial interface may 
be provided, whereby the debugger interface unit can scan in data to be added to the 
breakpoint registers. New attributes to be stored within the breakpoint registers may 
be provided to the debugger interface unit, these parameters then being stored into 

J the breakpoint registers for subsequent use by the breakpoint comparators. 

^^^■^^^oint comparator may, at any instant in time, be arranged to look 
at= either . instruction information from the instruction buses 160, 165, 170 or data 
infoimaiion from the data buses 180, 185, 190. If the breakpoint comparator is 
an^kffig instruction information from the instruction buses, and obtains a match with 

1 the attributes of the breakpoint registers, then a breakpoim signal is issued over path 
230 to the processor core. However, if the breakpoint comparator is arranged to 
analysfcdata information from the data buses 180, 185, 190, and obtains a match with 
the attributes of the breakpoint registers, then a "watchpoint" signal is issued over 
path 240 to the processor core 100. For the purposes of the following description of 
preferred embodiments, both the breakpoint signal issued over path 230 and the 
watchpoint signal issued over path 240 can be considered as breakpoint signals, as 
both;:Signals.will cause the processor core to stop processing instmctions. thereby 
enabling'the debugger to analyse the current state of the data processing apparatus 
prior to the execution of the breakpointed instruction. However, in preferred 

30 embodiments, separate paths 230. 240 are provided, so that the processor core 100 
can determine whether the signal received is a breakpoint signal relating to 
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instructions or a watchpoint signal relating to data. 

When the processor core 100 receives a breakpoint signal via the paths 230 
or 240, and hence stops processing instructions, it will issue a debug acknowledge 
signal over path 250 to the embedded ICE unit 150 to inform the embedded ICE unit 
150 that it has received the breakpoint signal, and has stopped processing instructions. 

In addition to the hardware breakpoint units 200 and 205. the embedded ICE 
unit 150 also contains a number of control registers 210 containing various items of 
data used to control the operation of the embedded ICE unit 150. However, in 
accordance with preferred embodiments of the present invention, a number of extra 
fields have been added to the control registers 210, these control registers being used 
by additional elements added to the embedded ICE unit to handle the issuing of 
breakpoint signals upon the occurrence of certain specified events. These further 
elements are illustrated in Figure 4, which provides a more detailed overview of the 
components within the embedded ICE utiit 150. 

As illustrated in Figure 4, a state machine 300 is provided to enable the 
debugger to step through the code being executed on the data processing apparatus, 
such that a predetermined number of instructions are executed, and dien the state of 
the processor and/or memory are examined before the next predetermined number of 
instructions are executed. In preferred embodiments, this state machine 300 is used 
to perform a single stepping process through the code, such that the code is executed 
one instruction at a time, and the state of the processor and/or memory are examined 
in between each instruction. An extra field is provided within the control register 210 
which is accessible by the state machine 300, and is settable to indicate that a 
stepping process is to be employed. If the field has been set, then the state machine 
is arranged to keep a record of the number of InMREQ signals issued by the 
processor core, and after a predetermined number of InMREQ signals have been 
received, the state machine 300 is then arranged to issue a breakpoint signal over path 
330 to the OR gate 320. If the state machine 300 is arranged to perform a single 
stepping process, then the state machine 300 issues the breakpoint signal once two 
InMREQ signals have been issued by the processor core. The operation of the state 
machine 300 will be discussed in more detail later with reference to Figures 5 to 7. 
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In accordance with preferred embodiments of the present invention the 
embedded ICE unit 150 also i™:ludes vector catch logic 310 which is arrang^I to 
i^ntify accesses to exception routines at exception addresses often referred to as 
-vector- addresses. A number of additional fields are added to die control registers 
5 210. each field corresponding to a particular exception routine, and each field being 
settable to indicate that the debugger wishes to identify an access to the corresponding 
exception routine. 

. : "I^e vector catch logic 310 is arranged to receive any InMREQ signals issued 
by the prpc^r core, and is also arranged to receive a qualifying signal which is set 
10 to indicate that the instniction fetch request referred to by the InMREQ signal is 
actually an instruction fetch request for an instruction of an exception nnitine. Upon 
.^^^^mPfm^ signals, the vector catch logic 310 is arranged to use a predeteimined 
number- of the bits in the address associated with the InMREQ signal, and the bits 
ared^within the various additional control registers corresponding to each exception 
J5 ^ #^«te..<|etennine which exception routine the address corresponds to. If the 
r inaction fetch command coixesponds to an exception routine whose corresponding 
. . fiel^Jri^he^control register has been set, then the vector catch logic 310 is arranged 
to issue a breakpoint signal over path 340 to the OR gate 320. A more detailed 
description of the operation of the vector catch logic 310 will be provided later with 
?0 refqienee to Figures 8 to 10. 

, ..In addition to the breakpoint signals issued by the state machine 300 and the 
vector catch Ipgic 310. the OR gate 320 is also arranged to receive any breakpoint 
signals issiied over paths 350 and 360 from die hardware breakpoint units 200 and 
.2p5^.Hence.if any breakpoint signals are issued by die components of the embedded 
25 ICE j^nitm then the OR gate 320 will issue a breakpoint signal over the path 370 
to^tte ^mcessdr core 100. 
^-..^--m^.a state machine 300 and vector catch logic 310 have been provided 
specficaUy^to Jiandle single stepping and the identification of accesses to exception 
..fOHlte,;.respectively. dien die hardware breakpoim units 200 and 205 are free to be 
30 used^fe^odier purposes, thereby enabling die debugger to perform some additional 
..debugging procedures whilst also performing single stepping or vector catch 
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processes. 

It will be appreciated by those skilled in the an that the above described 
embedded ICE unit 150 in accordance with preferred embodiments of the present 
invention is not restricted to use with a data processing apparatus having a Harvard 
architecture as illustrated in Figure 1. All that is required is for the embedded ICE 
unit 150 to be arranged to receive information about the instruction accesses and/or 
data accesses being initiated by the processor core. 

Hence, as illustrated in Figure 2. the embedded ICE unit 150 of preferred 
embodiments may be used in a data processing apparatus having a Von Neumann 
architecture, in which a single cache 400 is provided for storing both instructions and 
data values. In this arrangement, when the processor core 100 requires an instruction 
or a data value, it places the memory address of that instruction or data value on the 
processor address (PA) bus 410. Further, the processor core 100 issues a processor 
control signal on the processor control (PC) bus 420. This processor control signal 
is received by the cache controller 130. and prompts the cache controller to determine 
whether the required instruction or data value is stored within the cache 400. 
Further, an additional control signal is provided distinguishing between instruction 
and data fetches. The cache controller 130 instructs the cache 400 to compare the 
address on the address bus 410 with the addresses in the cache to determine whether 
the instruction or data value corresponding to that address is stored within the cache. 
If so, that instruction or data value is output from the cache 400 onto the processor 
data (PD) bus 415, where it is then read by the processor core 100. If the instruction 
or data value corresponding to the address is not within the cache 400, then the cache 
comroller 130 causes that instruction or data value to be retrieved from memory 140 
over the external bus 220. The retrieved instruction or data value is then stored in 
the cache 400 and remmed to the processor core 100 over the data bus 415. 

In addition to receiving instructions or data values over the processor data bus 
415. the processor core 100 may also output data values over the data bus 415 to the 
cache 400 for storage in the cache. These data values may then be later retrieved by 
the processor core 100 when required for subsequent processing operations. 

The embedded ICE unit 150 operates in the same way as described earlier 
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yjA^references to Figures 1 and 4. Hence, it is connected to the various bus lines 
410, 41Si 420 in order to receive the necessary information about instruction or data 
accesses being initiated by the processor core 100. For the purposes of single 
stepping or vector catching, the embedded ICE unit wUl only consider the instruction 
filches and not the data fetches. As described eariier with reference to Figure 4, the 
state machine 300 can then be used to allow the debugger to perform a single stepping 
process, and the vector catch logic 310 can be used to identify when accesses to 
exception routines are taking place, and to issue a breakpoint signal to the processor 
core so as to halt the processing performed by the processor core, and enable the 
(tebugger to analyse the state of the processor core and/or memory at that point. 
When a breakpoint signal is issued to the processor core over the path 370, then the 
processor core 100 will send a debug acknowledge signal over the path 250 to the 
emfeed^ed IGE unit 150 to confirm that it has halted its processing. 

in addition to being used with a data processing apparattis having either a 
15 Harvard architecture or a Von Neumann architecttire, the embedded ICE unit 150 of 
preferred embodiments may also be used with a data processing apparatus having no 
cache, such a data processing apparaftis being illustrated in Figure 3. As illustrated 
in: Figure 3 , the processor core 100 is connected to a memory 140 via the processor 
b^|j!in^ J50. 455, 460. When the processor core 100 requires an instruction or a 
) daa vahie, it places the memory address of that instruction or data value on the 
processor address (PA) bus 450. and also issues a processor control signal on the 
processor control (PC) bus 460. The processor control signal is received by the 
memory 140, and prompts the memory to retrieve the instruction or data value stored 
at the address output on the PA bus 450. Again, there is an additional control signal 
i provided distinguishing between instruction and data fetches. The retrieved 
instruction or data value is then output from the memory 140 onto the processor data 
(PD) bus.455, where it is then read by the processor core 100. In addition to 
i¥^iving instructions or data values over the PD bus 455, the processor core 100 
may also output data values over the PD bus 455 to the memory 140 for storage in 
theiSsemQiy . - 

: The embedded ICE unit 150 is connected to the various processor buses 450. 
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455, 460 in order to receive the necessary information about instruction or data 
accesses, and then operates in the same manner as described earlier with references 
to Figures 1, 2 and 4. 

Having described the general arrangement of the embedded ICE unit 150 in 
accordance with preferred embodiments of the present invention, the operation of the 
state machine 300 within the embedded ICE unit 150 will now be described in more 
detail with reference to Figures 5 to 7. 

Figure 5 is a timing diagram illustrating the relationship between a number of 
signals generated by the data processing apparatus of preferred embodiments when 
operating in a single stepping mode of operation. The vertical lines 520 have been 
added to indicate the separation between each clock cycle. The state of the state 
machine 300 (SM STATE) during these various clock cycles is indicated at the 
bottom of Figure 5. "I" indicating that the state machine is in the idle state, "Fl" 
indicating that the state machine is in the first fetch state, and "F2" indicating that the 
state machine is in the second fetch state. These states, and the relationships between 
them, are illustrated in Figure 6. 

During a first clock cycle "FEl", the processor core is arranged to fetch a 
first instruction. Hence, on the rising edge of the clock signal 500 during the 
proceeding clock cycle, the processor core will be arranged to issue an InMREQ 
signal 510 having a logic "0" value to initiate an instruction fetch, and at the same 
time will output the address of that instruction on the instruction bus. On the rising 
edge of the clock in the FEl clock cycle, the state machine 300 will notice that a first 
InMREQ signal has been issued by the processor on the control bus, and will hence 
exit the idle state, and move into the Fl state. At the end of the FEl clock cycle, the 
instruction data 530 corresponding to the first instruction fetch request will be 
returned on the instruction data (ID) bus. 

In the next clock cycle, the processor will be arranged to decode the first 
instruction (represented by the reference DEI in Figure 5), and will also fetch a 
second instruction from memory or cache (represented by the reference FE2 in Figure 
5). Between the rising edge of the clock in the FEl clock cycle and the rising edge 
of the clock in the FE2 clock cycle, the InMREQ signal will be asserted on the 



19 



control bus, and the corresponding address of the instruction will be output on the 
instruction bus. Further, upon the rising edge of the clock in the FE2 clock cycle, 
the state machine 300 will note that a second InMREQ signal has been issued, and 
hence the state machine will move from the Fl state to the F2 state. At the end of 
this FE2 clock cycle, the instruction data 535 corresponding to the second instruction 
request will be retun^ on the instruction data bus to the processor core, 

Furdier, since on the rising edge of the clock in the FE2 clock cycle, the state 
na^chine 300 noted that a second InMREQ signal had been issued, and hence a second 
instmction fetch was taking place, the state machine 300 will be arranged to assert 
Jie breakpoint signal 540 upon the falling edge of the clock of the FE2 clock cycle. 
,,,Tte relationship between the falling edge of the clock in the FE2 clock cycle, and the 
issuance of the breakpoint signal 540 is indicated by the arrow 560 in Figure 5. 
^ . In the next clock cycle, die processor 100 will be arranged to execute the first 
insttuction (represented by the reference EXl in Figure 5), and will also be arranged 
p€5^^ the second instruction (represented by the reference DE2 in Figure 5). 
Further, the processor will fetch a third instruction from memory or cache, and so 
a third InMREQ signal will be asserted. On the rising edge of the clock in this clock 
cycte, the state machine 300 will note that a third InMREQ signal has been issued, 
and will also note that the debug acknowledge signal 550 from the processor core 
,: l)ack to.th? embedded ICE unit 150 is still low, this indicating that the processor core 
|00 has not yet stopped processing instructions. In this siniation, the state machme 
will remjiin in the F2 state as illustrated in Figure 6, since it will only return to the 
Me state once the processor has stopped. 

: Since the state machine 300 has not received a logic "1" level debug 
IQlgio^ledge signal 550, at the end of this clock cycle it will be arranged to re-assert 
r the brealq>oiiit signal 540 in the next clock cycle. Since the first instruction may be, 
for exano^^le, a branch, and hence it cannot automatically be assumed that the second 
^ipstnttrtion will be executed immediately after the first instruction, the breakpoint 
signal is preferably re-asserted for each subsequent instruction fetched until the debug 
acknowledge signal 550 is asserted. Instructions will continue to be fetched until the 
processor has processed the breakpointed instruction, ie. until that instruction reaches 
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the execution stage of the pipeline, at which point the debug acknowledge signal will 
be asserted by the processor. 

With reference to Figure 5, since in the next clock cycle, the processor core 
will have executed the first instruction, and will have received the breakpoint signal 
5 540, the processor core will then be arranged to stop processing instructions, and to 
issue the debug acknowledge signal 550 on the rising edge of the clock in this next 
clock cycle. Hence, the second instruction that had been fetched and decoded in the 
previous clock cycles will not be executed in this clock cycle. Thus, on the rising 
edge of the clock in this clock cycle, the state machine 300 will note the presence of 

10 the debug acknowledge signal 550, indicating that the processor has stopped, and will 
hence return to the idle state. Then, on the falling edge of this clock cycle, the data 
processing apparatus will enter the debug state, in which the InMREQ signal stays 
high indicating that no instruction fetch is taking place, the breakpoint signal 540 will 
stay low, since the processor core has now responded to the breakpoint signal, and 

15 hence the breakpoint signal need no longer be generated, and the debug acknowledge 
signal 550 will remain high indicating that the processor has stopped. 

When the debugger has finished analysing the state of the processor core 
and/or memory, then the clock will be switched back on, and the debug acknowledge 
signal 550 will return to the logic "0" level on the first rising edge of the clock. 

20 Further, the processor core will issue an InMREQ signal 510 to request that the 
second instruction be re-fetched. As illustrated in Figure 5, the whole single stepping 
process is then repeated for the second instruction, resulting in the data processing 
apparatus re-entering the debug state once the second instruction has been executed. 
Figure 6 sunmiarises the state of the state machine as discussed above with 

25 reference to Figure 5. Hence, the state machine 300 remains in the idle state 600 
until the first instruction fetch takes place, at which point the state changes to the Fl 
state 610. Then, when a second instruction fetch takes place, the state machine 
moves from the Fl state to the F2 state 620. The state machine 300 then remains in 
the F2 state 620 until the debug acknowledge signal 550 is received to indicate that 

30 the processor has stopped, at which point the state machine returns from the F2 state 
620 to the idle state 600. 
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The circuitry used in preferred embodiments to provide the function of the 
state machine 300 is illustrated in Figure 7. The logic 700 is arranged to receive the 
InMREQ signal, which has a logic "0" value when an instruction fetch is being 
issued, the debug acknowledge (DBGACK) signal, which has a logic "1" value when 
the processor has stopped, and a CTL signal, which is the value of the bit in the 
-«^l; register 210 set to indicate whether single stepping is to be employed or not. 
the CTL signal having a logic "1" value when a single stepping process is to ht 
performed. The logic 700 is also arranged to receive two bits of information 
representing the state of the state machme. these two bits being referred to as the 
"StepSaie". The value of StepSlate [1:0] is dependent on the "NextState [1:0]" 
signal output by the logic 700 to indicate the next state of the state machine 300. The 
relationship between the various input signals to the logic 700 and the value of 
NextState [1:0] output from the logic 700 in accordance with preferred embodiments 
oT die present invention is illustrated in the following table: 



StepState[l:0] 


InMREQ 


DBGACK 


CTL 


NextState[l:0] 


XX 


X 


X 


0 


00 


XX 


X 


1 


X 


00 


,0Q 


0 


0 


1 


01 


01 


0 


0 


1 


10 


10 ' 


0 


0 


1 


10 



In th^ above table, the value "00" corresponds to the idle state of the state 
ma<^ine 300. the value "01 " corresponds to the Fl state of the state machine 300, 
and the value "10" corresponds to the F2 state of the state machine 300. 

When the power is first supplied to the data processing circuit, a reset signal 
passed over path 715 to the D-type register 710. and also to D-type latch 720. The 
reset signal causes the D-type register 710 to output the value "00" as the SiepState, 
and causes the D-type latch 720 to reset the "StepBkpt" signal to zero. 
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With reference to Figure 5, during the FEl clock cycle, the InMREQ signal 
will be low, the DBGACK signal will be low, and the CTL signal will be high, 
assuming single stepping is to take place. Assuming the step state is "00", then the 
above table indicates that "NextState" will be "01", corresponding to the Fl state. 

The D-type register 710 will receive this NextSute value, and will also receive 
the clock signal over the path 730. On the rising edge of the clock during the FEl 
clock cycle, the D-type register 710 will output the NextState value, i.e. "01" as the 
StepState, this StepState then being input to the logic 700. Further, bit one of the 
StepState is passed over path 760 to the AND gate 780. The AND gate 780 is also 
arranged to receive the inverted DBGACK signal (via inverter 770). Since the first 
bit of the StepState signal is. in this case, zero, the signal output by the AND gate 
780 will be zero. 

The D-type latch 720 will receive the output from the AND gate 780, and also 
the clock signal 730. and on the falling edge of the clock in the FEl clock cycle, will 
output the signal received from the AND gate 780 as the signal StepBkpt. Since the 
signal from the AND gate 780 is. in this case, zero, the StepBkpt signal is also zero. 

In the next clock cycle, InMREQ and DBGACK will both be low, CTL will 
remain high, and now the StepState is "01". As illustrated in the above table, the 
next state output by the logic 700 will hence be "10". Hence, on the rising edge of 
the clock in this next clock cycle, the state " 10" will be output as the StepState by the 
D-type register 710, this corresponding to the F2 state of the state machine 300. 

The AND gate 780 will receive a logic " 1 " value from the inverter 770. since 
the DBGACK signal is zero. Further, since the first bit of this StepState value is "1". 
then the AND gate will also receive a logic "1" signal at its second input, and so will 
output a logic "1" signal to the D-type latch 720. Hence, a logic "1" signal will be 
output as the StepBkpt signal upon the falling edge of the clock cycle by the D-type 
latch 720. This StepBkpt signal is the signal output by the state machine 300 over 
the path 330 to the OR gate 320, as illustrated in Figure 4, and this will result in a 
breakpoint signal being issued to the processor core. 

In the third clock cycle, InMREQ and DBGACK will once again remain low, 
CTL will be high, and now the StepState signal will be "10". As indicated by the 
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last line in the table, the next states output by the logic 700 will remain at the value 
"10". and hence on the falling edge of this clock cycle, the StepBkpt signal will once 
i^ain have a "1" value. 

r v:. This state of affairs will persist until such time as the processor core issues a 
1^ ©BGAGK signal to indicate that the processor has stopped. As indicated by the 
second entry in the above table, irrespective of the values of the StepStaie. the 
: loMREQ signal, or the CTL signal, the presence of a high DBGACK signal wiU 
cause the next state output by the logic 700 to be "00". Further, since the inverted 
DBGACK signal is also supplied to the AND gate 780. this will cause the AND gate 
10 to output a zero value irrespective of the value of StepState[l]. Hence, on the falling 

edge ofthe dock cycle, the StepBkpt signal wUl return to a -0" value. 

. . Having described the operation of the state machine 300, the operation of the 
vector catch logic 310 provided within the embedded ICE unit 150 in accordance with 
preferred embodiments will now be described in more detail witfi reference to Figures 

Figure 8 is a timing diagram illustrating the various signals generated by the 
data processing apparatus of preferred embodiments when employing the vector catch 
logic 310 to identify an access to an exception routine when exceptions, for example 
data aborts., occur. The interaction of the various signals Ulustrated in Figure 8 are 
0 f«er illustrated in Figure 9. which is a block diagram illustrating the main elements 
pf^^ipetar catch logic 310. 

- The vertical lines 880 in Figure 8 have been included to Uhistrate the 
sepaiatipn-between the various clock cycles. In the event that an exception occurs, 
flie processor core 100 will be arranged to issue an instruction fetch request to 
ret^ve flie first instruction of an exception routine used to handle that exce^jtion. 
Hence, in addition to issuing the InMREQ signal, the processor core will also issue 
the address 810 on the instruction address bus. this address corresponding to the 
address of the -first instruction in the exception routine. At the same time, a 
qualifying signal will also be output by the processor core 100. preferably this 
qualifying signal being output on the comrol bus in addition to the InMREQ signal, 
this Mgnal iiKlicating that the instniction fetch relates to an instruction of an exception 
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routine. In preferred embodiments, this qualifying signal is referred to as a 
"VectAdd" signal, and is illustrated in Figure 8 by the line 820. 

As illustrated in Figure 9, the instruction address information and the VectAdd 
signal are input to decode logic 900 within the vector catch logic 310. In preferred 
embodiments, only bits 4 to 2 of the instruction address are input into the decode 
logic 900, since in preferred embodiments only these bits are required in order to 
determine which exception routine is being accessed. However, it will be appreciated 
by those skilled in the art that any number of the bits of the instruction address may 
be provided to the decode logic 900, as required. 

The decode logic 900 also has access to the vector catch registers 930, these 
being the extra fields of the control registers 210 within the embedded ICE unit 150 
referred to earlier with reference to Figure 4. In preferred embodiments, there are 
eight exception routines, and hence eight fields within the vector catch register 930. 
Further, each field preferably contains one bit which is settable to indicate whether 
the debugger wishes to identify an access to the corresponding exception routine. 

Assuming the VectAdd signal is high, indicating that an access to an exception 
routine is taking place, then the decode logic 900 is arranged to use bits 4 to 2 of the 
address, and the corresponding bits from the vector catch registers 930 to determine 
which exception routine is being accessed, and further whether the corresponding bit 
in the vector catch registers 930 has been set. The actual logic contained within the 
decode logic 900 in preferred embodiments of the present invention to perform the 
above function will be described in detail later with reference to Figure 10. 

Assuming the corresponding bit in the vector catch register 930 indicates that 
the debugger does wish to identify an access to the determined exception routine, then 
a "VDecode" signal is output by the decode logic 900 over path 940 to a D-type latch 
910. This VDecode signal is illustrated by the line 830 in Figure 8, and it will be 
seen that it is of a similar form to the VectAdd signal, but displaced in time due to 
the time taken by the decode logic 900 to perform the necessary processing. 

The D-type latch 910 is also arranged to receive the clock signal over the path 
970 and hence on the falling edge of the clock is arranged to output the VDecode 
signal as a "VTest" signal over the path 950. This VTest signal is illustrated by the 
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line 840 in Figure 8, and it will be seen that the VTest signal is output after the 
falling, edge of the clock indicating the beginning of the fetch cycle. 

The VTest signal is received by another D-type latch 920, which is also 
arranged to receive the clock signal over path 970. Hence, upon the fallmg edge of 
the clock at the end of the fetch cycle, the D-type latch 920 is arranged to output the 
y;?[f St signal as a "VBkpt" signal over path 960, this VBkpt signal corresponding to 
the signal output by the vector catch logic 310 over the path 340 to the OR gate 320, 
as illustrated earlier with reference to Figure 4. Hence, the OR gate 320 within the 

T^f imbedded ICE unit 150 illustrated in Figure 4 will be arranged to output the 
breatkpoint signal upon receipt of the VBkpt signal from the vector catch logic 310. 
13s? VBkpt signal is illustrated by the line 850, and the breakpoint signal is illustrated 
J?3^3*y^^ 860, in Figure 8. It can be seen from Figure 8 that the breakpoint signal 
W) is issued fractionally after the VBkpt signal 850, due to the time taken for the 
signal to, pass from the vector catch logic 310 to the OR gate 320, and be processed 
by the OR gate 320. 

- -Finally, with reference to Figure 8, the instruction data 870 corresponding to 
the address 810 issued on the instruction address bus is returned to the processor core 
on the instruction data bus towards the eiKl of the fetch cycle. 

; From the above description of Figures 8 and 9, it will be appreciated that the 
above approach ensures diat the breakpoint signal is asserted in the clock cycle 
inWS^iately following the fetch cycle during which an exception routine instruction 
is> fetched.- Hence, the processor core will be forced to stop processing prior to 

-exei|B|oii ^^^^ instruction. Since, by its nature, an exception routine instruction 
will be executed without delay, it is sufficient just to assert the breakpoint signal once 
as illusu^ted m Figure 8. 

Figure 10 illustrates in more detail the decode logic 900 shown in Figure 9. 
As illustrated in Figure 10, the decode logic 900 receives bits 4 to 2 of the instruction 
addlress over path 980, receives the VectAdd signal over path 990, and receives the 
eigjhti bils from the vector catch register over the path 985. The bits 4 to 2 of the 
5||p|t|c^ address are inverted by the inverter 992 to form an inverted address NA 
[2:01, and this signal is then inverted again to form the buffered addressed bits BA 
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In preferred embodiments, the first exception routine will be being accessed 
if bits 4 to 2 of the instruction address are all "0", and hence if bits 2 to 0 of the NA 
signal are all " Ts. Further, bit 0 of the vector catch registers 930 corresponds to this 
5 exception routine, and hence bit 0 of the vector catch register is passed to AND gate 
996, along with bits 2 to 0 of the NA signal. Further, the AND gates 996 receive 
the VectAdd signal over path 990, this being high whenever an instruction fetch to 
an exception routine is taking place. 

Hence, with reference to Figure 10, it will be appreciated that the AND gate 

10 996 will only output a level "1 " signal if bits 2 to 0 of the NA signal are high, if bit 
0 of the vector catch register is high (to indicate that the debugger wishes to identify 
an access to the first exception routine), and if the VectAdd signal is high to indicate 
that an access to an exception routine is taking place. 

Similar AND gates 998, 999 are provided for each of the other seven bits of 

15 the vector catch register 930, these AND gates 998, 999 also being arranged to 
receive selective bits from either the NA signal or the BA signal, depending on the 
particular exception routine. Hence, as an example, the second exception routine will 
be being accessed if bits 4 and 3 of the instruction address are 0, and bit 2 of the 
instruction address is 1. In that instance, bits 2 and 1 of the NA signal will be high, 

20 and bit 0 of the BA signal will be high, and hence these bits are routed to the AND 
gate 998 in addition to bit 1 of the vector catch register. It will hence be appreciated 
that if the second exception routine is being accessed, and bit 1 of the vector catch 
register has been set high to indicate that the debugger is interested in identifying an 
access to that second exception routine, then the AND gate 998 will issue a high 

25 signal to the OR gate 1000 so long as the VectAdd signal is high to indicate that an 
access to an exception routine is taking place. 

As a final example, the eighth exception routine will be being accessed if bits 
4 to 2 of the instruction address are all high, and hence if bits 2 to 0 of the BA signal 
are high. Hence, AND gate 999 is arranged to receive bits 2 to 0 of the BA signal, 

30 and bit 7 of the vector catch register 930. Hence if that bit of the vector catch 
register has been set, and the corresponding bits 2 to 0 of the BA signal are high, 
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then the AND gate 999 will output a logic T signal to the OR gate 1000. assuming 
the VectAdd signal is high, to indicate that an access to an exception routine is taking 
place. 

Whenever the OR gate 1000 receives a logic "1" signal from any of the AND 
gates 996, 998. 999, it will output the VDecode signal as a logic "1" value. 

From the above description of a data processing apparanis in accordance with 
preferred embodiments of the present invention, it will be appreciated that the 
provision of a dedicated state machine 300 and vector catch logic 310 to perform 
.single stepping functions and identification of accesses to exception routines, 
.resp«;tively, provides a particularly efficient technique for handling these common 
i^^ging requirements, whilst leaving any general hardware breakpoint units 
provided^ within the embedded ICE unit free to be used for other purposes. 

Although a particular embodiment has been described herein, it will be 
^appr^jiated tfiat the invention is not limited thereto and that many modifications and 
.^itrons thereto may be made within the scope of the invention. For example, 
vanpMs combinations of the features of the foUowing dependem claims can made 
with the feanires of the independent claims without departing from the scope of the 
present invention. 
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CLAIMS 



1. A debugger interface unit for a data processing apparaftis, comprising: 

a control register having a number of fields, each field corresponding to a 
particular exception routine, and each field being settable to indicate that the debugger 
wishes to identify an access to the corresponding exception routine; 

an exception routine catch logic arranged to receive a first signal when a 
processor core within the data processing apparatus issues an instruction fetch 
command for an exception routine, and to determine from an instruction address 
issued with the instruction fetch command which exception routine is being fetched; 

the catch logic further being arranged to reference the field of the control 
register corresponding to the determined exception routine to determine if that field 
has been set. and if the field has been set, to output a breakpoint signal to the 
processor core. 

2. A debugger interface unit as claimed in Claim 1, wherein the first signal is a 
signal output by the processor core on a control bus to request an instruction fetch for 
an exception routine to be performed. 

3. A debugger interface unit as claimed in Claim 2, wherein the first signal 
consists of a signal output by the processor core to indicate that an instruction fetch 
is required and a qualifying signal to indicate that the instruction fetch relates to an 
exception routine. 

4. A debugger interface unit as claimed in any of claims 1 to 3, wherein each 
field contains a single bit to indicate whether the debugger wishes to identify an 
access to the corresponding exception routine. 
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5. A debugger interface unit as claimed in any preceding claim, wherein the 
catch logic is arranged to determine from predetermined bits of the instruction address 
issued with the instruction fetch command which exception routine the instruction 
fi^^jpumd relates to. 

6. A debugger interface unit as claimed in any preceding claim, further 
cc^nprising: 



15 



an ii^t terminal for receiving information about instruction or data accesses being 
10 initiated by the processor core; 

one or more hardware breakpoim units, each breakpoint unit having a number of 
breakpoint registers for storing attributes of instruction or data accesses that are to 
cause. the breakpoint signal to be sent to the processor core, and a breakpoint 
comparator for comparing the attributes in the breakpoint registers with the 
information received at the input terminal; 



each breakpoint unit being arranged to issue said breakpoint signal if die breakpoint 
comparator matches the attributes in the breakpoint registers with corresponding 
0 attributes contained in the information received by the input terminal. 

7. A debugger interface unit as claimed in Claim 6, wherein the input terminal 
is connected to an address bus. a data bus. and a control bus for receiving the 
information about instruction or data accesses being initiated by the processor core. 



8. A debugger interface unit as claimed in Claim 6 or Claim 7. further 
comprising a logic gate for receiving the breakpoint signal issued by any of the 
bre^int units or the catch logic, and for outputting a single signal to the processor 



core: 



A debugger interface unit as claimed in any of claims 6 to 8, further 
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comprising an interface for receiving attributes from a debugger for storing in the 
breakpoint registers. 

10. A debugger interface unit as claimed in any preceding claim, wherein the 
5 control register has a further field settable to indicate that a stepping process is to be 

employed, the debugger interface further comprising: 

a state machine arranged to receive a second signal when a processor core 
within the data processing apparatus requests an instruction fetch to take place, the 
10 state machine being arranged to keep a record of the number of instruction fetches 
requested by the processor core; 

the state machine further being arranged to reference the control register to 
determine whether the further field has been set, and, if the further field has been set, 
1 5 to output the breakpoint signal to the processor core once a predetermined number of 
instruction fetches have been requested by the processor core. 

11. A debugger interface unit as claimed in Claim 10, wherein the predetermined 
number of instruction fetches is two, and the stepping process is a single stepping 

20 process. 

12. A debugger interface unit as claimed in Claim 10 or Claim 11. wherein the 
second signal is a signal output by the processor core on a control bus to request an 
instruction fetch to be performed. 

25 

13. A data processing apparattis, comprising: 
a processor core for executing instructions; 

30 a debugger interface unit as claimed in any preceding claim. 
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14. : A data processing apparatus as claimed in Claim 13, further comprising: 
an instruction cache for storing instructions; 
a data cache for storing data; 

an instruction address bus and an instruction data bus being arranged to connect the 
instruction cache with the processor core, the instruction address bus enabling the 
;piocess6r core to output instruction addresses to the instruction cache, and the 
instruction data bus enabling the processor core to receive instructions corresponding 
to those instruction addresses; and 

a data address bus and a data data bus being arranged to connect the data cache with 
the processor core, the data address bus enabling the processor core to ouQmt data 
iacpi^ to tl» data cache, and the data data bus enabling the processor core to 
receive data values corresponding to those data addresses, or to aatput data values to 
tlw data cache. : . .• 

15. A data processing apparams as claimed in Claim 14 when dependent on Claim 
6, wherein the input terminal of the debugger interface unit is connected to the 
instruction address bus and the instruction data bus for enabling the one or more 
hardware breakpoint units to receive the necessary information about instruction 
accesses required by the breakpoint conq)arator. 

16. A data processing apparatus as claimed in Claim 14 or Claim 15 when 
dei^atent on Claim 6, wherein the input terminal of the debugger interface unit is 
connected to the data address bus and the data data bus for enabling the one or more 
hardware breakpoint units to receive the necessary information about data accesses 
required by the breakpoint comparator. 



17. A method of operating a debugger interface unit for a data processing 
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apparatus to identify an access to an exception routine, comprising the steps of: 

(a) providing a number of fields within a control register, each field 
corresponding to a particular exception routine; 

5 

(b) setting one of said fields to indicate that the debugger wishes to identify an 
access to the corresponding exception routine; 

(c) receiving a first signal when a processor core within the data processing 
10 apparams issues an instruction fetch command for an exception routine; 

(d) determining from an insuiiction address issued with the instruction fetch 
command which exception routine is being fetched; and 

15 (e) if the field of the control register corresponding to the exception routine 
determined at said step (d) has been set. outputting a breakpoint signal to the 
processor core. 

18. A debugger interface unit as claimed in Claim 1, substantially as hereinbefore 
20 described with reference to the accompanying drawings. 

19. A data processing apparatus as claimed in Claim 13, substantially as 
hereinbefore described with reference to the accompanying drawings. 



25 20. A method of operating a debugger interface unit as claimed in Claim 17, 
substantially as hereinbefore described with reference to the accompanying drawings. 
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